Rethinking the Well-Architected Review
The Well-Architected Review (WAR) has become so ubiquitous that it often feels like the default framework for cloud infrastructure. Many of my clients have used a WAR to find gaps and areas for improvement.
As a consultant, I’ve seen a broad range of WAR implementations. At their core, they aim for the greater good, through clear design and clear operations. But there’s one key aspect often overlooked in practice: a sense of what is truly needed.
Like all engineering endeavors, building cloud platforms involves trade-offs. I often see WAR implementations that merely echo the cloud provider’s generic prescribed best practices. The providers are, of course, well-positioned to define a “well-architected” environment, but they also have a vested interest in steering customers toward greater adoption. This sometimes comes at the detriment of efficiency and flexibility.
The Challenges of "Well-Architected" Overhead
I’ve worked with several clients whose environments were perfectly aligned with well-architected principles. Yet they struggled to meet their actual needs.
These organizations shared a few common traits:
- 6+ accounts carefully segmented for master, production, dev/QA, staging, logging, audit, and more.
- Fewer than five contributors managing the entire setup.
- Frustration with the complexity of cross-account navigation and role management.
These setups came from agency engagements or manual implementations of best-practice documents. Layouts like that make sense for larger, mature organizations, they can burden smaller teams, bogging them down in operational inefficiencies.
The result? Too much time spent navigating a Landing Zone trying to get to where the work needs to happen.
Platform architecture should align with the needs of the organization. A one-size-fits-all approach to platforms rarely delivers an optimal balance of usability and functionality.
I use the following questions when guiding my clients in their account separation journeys.
1. Is there an external requirement for account separation?
If regulatory mandates or client agreements require separation of concerns, then the decision is made for you. Compliance always comes first.
2. Are there more accounts than contributors?
This is typically a red flag to me. It also raises an important follow-up: Will your team grow to the point where individuals or teams regularly work in each account within the next 12 months?
If not, scaling down account separation can save significant time and effort. If growth is expected, planning for (some) account-based separation early might make sense.
3. Do you manage your infrastructure as code (IaC)?
Infrastructure as Code (IaC) is non-negotiable, and it's doubly true when the infrastructure spans multiple accounts. It’s the foundation for managing, scaling, and maintaining consistency across environments. Without it, even mature organizations can struggle with sprawling, hand-crafted architectures that make management tedious and harder than needed.
4. Do you have a solid CI/CD pipeline?
Continuous Integration (CI) and Continuous Delivery (CD) are critical for reducing manual deployment processes. Building this capability early delivers immediate benefits in agility and reliability. Integrating this with a new account will be easier, than implementing a pipeline after you have a lot of account separation.
Where to start when it's time?
A multi-account setup doesn’t have to be an all-or-nothing decision. It’s perfectly fine to start with a single account and introduce role-based access controls (RBAC) before moving toward full account separation.
A good first step is isolating production into a dedicated account. This approach not only secures critical workloads but also serves as a proving ground for your IaC processes. If spinning up a new production environment isn’t feasible, start with development. But if possible, beginning with a clean slate in production is ideal.
Simultaneously, (this is important) introduce a master account to centralize user and permission management. Nothing spirals out of control faster than manual IAM credential handling across multiple accounts.
Finding the Right Balance
These rules of thumb have served me and my clients well. Ultimately, platform architecture needs to strike a balance. The system needs to be usable and useful to those working in it.
Over-building early on is just another form of technical debt.